The transport of data in packet-based communication systems normally requires that the data are subdivided into data blocks which fit into the packets. However, various services and applications exist which provide their data already in the form of data is blocks to the communication system. For example, a speech service such as Voice over IP (VoIP) may require the transmission of one data block with a constant or slightly varying size, e.g. 32 byte to 38 byte, every 20 milliseconds from the transmitter towards the receiver. With their sizes predetermined by the respective service or services, one or more data blocks may or may not fit into a packet size provided by the underlying communication system.
Therefore, in the general case, one or more data blocks will not fit exactly into one packet. Rather, after inserting the one or more data blocks into a payload portion of the packet and after constructing a header portion, there will be some residual space left over in the packet. The residual space may span a few bits or bytes only, but may also involve the larger part of the available payload ('payload' and ‘payload portion’ will be used synonymously hereinafter, as well as ‘header’ and ‘header portion’). The residual space may not be used for transporting any data, in which case it is filled with padding, i.e. with bits or bytes not representing any information. Some communication systems provide the possibility to use the capacity provided by the residual space in the packets for the transport of signalling between transmitter and receiver; for example, low priority or small bandwidth control data may be transported in this way, i.e. when a residual space is available. For brevity, however, in the following discussion it will be assumed that a residual space is filled with padding. Basically, the residual space is a waste of bandwidth which poses a problem for bandwidth-limited communication systems such as wireless systems.
The possible occurrence of residual space also leads to an overhead in controlling a packet-based data transmission. This comes from the necessity to indicate the padding in the packet header. For example, in systems which add padding in the form of a padding block at the end of the payload, it has to be indicated to the receiver where the last data block ends and the padding block starts. The control of padding may in certain situations lead to a massive overhead; for instance, it is possible that two packets are required for the transport of a data block, although the data block itself (and its associated header portion) would fit into a single packet. However, the padding plus the associated header portion for the padding then leads to the two packets being required. In general, therefore, the control of residual space in a packet-based data transmission system is a non-trivial task.
As an example for a data transmission system, consider a MAC (Media Access Control) protocol, in which a MAC transmitter encapsulates data blocks called MAC service data units (SDUs) and/or MAC control messages in a MAC packet called a MAC Packet Data Unit (PDU). In a particular MAC protocol which may form part of the upcoming UMTS (Universal Mobile Telecommunications System) LTE (Long Term Evolution) wireless communication system, the header portion comprises one sub-header for each SDU.
Each sub-header comprises as a field a Radio Bearer ID (RBID) or Logical Channel ID (LCID), which indicates the radio bearer the respective data block is associated with. The RBID field allows multiplexing several data streams on the MAC layer. A MAC PDU may comprise several SDUs associated with different radio bearers. As to the notation used herein, the term ‘information element’ (short IE) is used as relating to a mandatory or to an optional element in a header or sub-header.
Each sub-header comprises an extension flag as a mandatory sub-header field. In each except the last sub-header the extension flag is set, which indicates that a further sub-header follows. In case of a set extension flag, a length field is present in the sub-header for indicating a length of the MAC SDU the sub-header is associated with. However, the last sub-header does not require a length field, as the receiver may determine the length of the corresponding data block from the previous length fields and the packet size (also termed ‘transport block size’ in the MAC framework) it has determined when receiving the packet.
A number of packet sizes (transport block sizes, TBS) are predefined for the MAC PDUs in any given communication system. For example, packets with a TBS of 32 bytes, 40 bytes, 48 bytes etc. may have been defined in a particular system. In case one or more SDUs and the MAC header do not exactly fit into a transport block provided by a lower layer, remaining bits have to be filled with padding. Of course, the more packet sizes are available, the less amount of padding will be required on average.
As an example, according to a particular MAC protocol, a MAC PDU with a TBS of 40 bytes may comprise a single SDU of 38 bytes. The MAC header then comprises a single sub-header only, which may have a length of 2 byte, e.g. 8 bits for the RBID, 1 bit for the extension flag and 7 bits other IEs or header padding (regarding header padding, many communication systems require byte-aligned headers: Therefore if the fields in the header do not exactly fill one or more bytes, some header padding is required to achieve a byte-aligned header). No residual space is left over in this case, i.e. no padding is required in the payload.
One approach for inserting a padding block into a MAC PDU is to insert a sub-header for the padding block into the header, similar to inserting a sub-header for a further data block. The RBID field in the sub-header for the padding block takes a predefined special value. The sub-header for the padding block may be the last sub-header in the header, if the padding is filled into the payload at the end of the packet. Therefore, the length field of the last sub-header associated with a data block indicates the end of the information-carrying data. The receiver may derive from the special value of the RBID field in the very last sub-header that the remaining space in the payload is residual space filled with padding.
Inserting into a MAC PDU the length field of the second last sub-header (the last sub-header associated with a data block), and inserting the sub-header for the padding block requires some space within the packet. This does not matter if the residual space is larger than the space required for inserting the additional sub-header fields, i.e. length field, RBID field and extension flag. However, it does matter if the residual space is below the space required for inserting the additional sub-header fields.
Consider, as in the example above, a packet with a TBS of 40 bytes, wherein a sub-header without length field may occupy 2 bytes. A length field may occupy 1 byte. Therefore two sub-headers lead to a minimum header size of 5 bytes, as the first sub-header includes as a mandatory field the length field. 5 bytes then is also the minimum header size in case some padding has to be included. For simplicity it is assumed that a single SDU only has to be transported. In this case, an SDU with a size of 38 bytes can be transported without padding (as above). Further, SDUs with sizes between 1 to 35 bytes can be transported. Padding is required in this case. A corresponding sub-header is inserted, such that the header size amounts to 5 bytes. The sub-header addresses the padding block with a size between of 34 bytes to 0 bytes (0 bytes means no padding block).
In case, however, the SDU has a size of 36 bytes or 37 bytes, it is determined in the transmitter that for a residual space of 2 bytes or 1 byte a sub-header has to be included to address a corresponding padding block. Therefore, two sub-headers leading to a header size of 5 bytes are included in the packet, which requires that the 36 byte or 37 byte SDU has to be subdivided into two data blocks, which have to be transported in two packets (data are received by the MAC layer from a higher layer protocol in the form of an SDU; the MAC layer handles these data in the form of one or more data blocks or packet data units, PDU). The first packet carries the 5 byte header and a first data block with 35 bytes. The second packet carries the remaining 1 byte or 2 bytes of the original SDU. If there are no further data to be transported, the second packet carries only the one or two remaining bytes of the original SDU and 33 bytes or 34 bytes of padding.
Another approach for inserting a padding block into a MAC PDU comprises to include a mandatory field into the header for indicating a length of a padding block. This field must have a sufficient length to allow addressing the maximum amount of padding that may occur. Therefore, such a header field introduces a permanent overhead to the packet-based transmission system which may be undesirable.